Cream of the Crop 1/Cream of the Crop 1.iso/EDUCATE/QMTEK601.ARJ/TOPS.TEC

Text File | 1991-03-12 | 10KB | 175 lines

ID:TP TOPS network, DESQView and QEMM 386
by TOPS Corp. Technical Support #163
April, 1989

                            OVERVIEW

DesqView is a multi-tasking windows environment for DOS-based
machines, made by Quarterdeck Office Systems in Santa Monica, CA.
The current version (as of January, 1989) is 2.22.  It can be run
on any machine running DOS 2.0 or higher, on an 8088, 8086,
80286, or 80386 microprocessor.  On 386-based machines, it is
most commonly used in conjunction with Quarterdeck's 386 Expanded
Memory Manager, QEMM-386, to form a combination generally
referred to as DesqView386.  You can run DesqView on a 386
without QEMM-386, but you lose significant memory-management
capability, ending up with an environment virtually identical to
DesqView on a 286, only faster.  The current version of QEMM-386
(as of January, 1989) is 4.23.  Note that DesqView and QEMM-386
are separate products which must be purchased separately, and can
be used together, or independent of one another.  For the reason
stated above, it is rare to find someone running DesqView on a
386 without QEMM-386.  However, for reasons which will become
clear, many people who do not own DesqView buy and use QEMM-386
as their 386 Expanded Memory Manager of choice.  In fact, we may
wish to recommend QEMM-386 as a solution to TOPS/DOS users on 386
machines who are having trouble running their applications in
conventional RAM.

QEMM-386 has two major functions.  Firstly, it can transform a
386's standard 'extended' memory into 'expanded' memory (LIM EMS
4.0 and EEMS 3.2), which can then be accessed by programs
designed to take advantage of expanded memory, as well as by
DesqView, which can use it to create 'virtual' DOS environments
for simultaneous operation of multiple programs.  Secondly, it
can map RAM into the unused addresses between 640K and 1MB (so-
called 'HIGH DOS RAM') and allow a user to load TSR modules (such
as TOPS modules, for example) into it, thus making more
'conventional' RAM available to applications.  These two
functions are optional, and can be managed independent of one
another, but the first will have a significant impact on the
second, for the following reason.  How much HIGH DOS RAM is
available is a function of the particular machine architecture
and attached peripherals (display adapter, etc.) AND of whether
or not you invoke Expanded Memory Emulation.  Managing Expanded
Memory requires a 64K page frame in HIGH DOS RAM.  (DesqView can
perform many of its expanded memory operations without a page
frame, but most applications that use expanded memory require the
page frame to access it.) This function will therefore reduce the
amount of HIGH DOS RAM available to TSRs by 64K.  Obviously, from
the point of view of someone who merely wishes to get TOPS 'out
of the way', it would be best to disable Expanded Memory
Emulation.  But the price one pays is effectively rendering
useless all that expensive Extended Memory with which one's 386
is loaded.  This presents an interesting dilemma for someone
running TOPS and QEMM-386 without DesqView.  Do they disable
Expanded Memory Emulation, get as much as possible of TOPS into
HIGH DOS RAM, and have the maximum amount of conventional RAM
(but no Expanded RAM) available for their applications? Or,
conversely, do they enable Expanded Memory Emulation, which
forces them to put more of TOPS into conventional RAM, but makes
Expanded RAM available to their applications? If you are running
DesqView386, you get less benefit out of disabling Expanded
Memory Emulation, since DesqView can use half of the page frame
area anyway to clear its code out of conventional memory, and
since certain DesqView features require a page frame.

QEMM-386 consists, mainly, of a device driver (QEMM.SYS) and two
command- line utilities (QEMM.COM and LOADHI.COM).  QEMM.SYS is
loaded from CONFIG.SYS with a command of the form:
DEVICE=[d:][path]QEMM.SYS [options].  If QEMM.SYS is installed,
DesqView, when launched, will recognize it, and take advantage of
the services it provides.  QEMM.SYS works by using the 'virtual
8086' mode of the 386 microprocessor to provide such services as
Expanded Memory Emulation.  It has three possible 'states' in
this regard - AUTO, ON and OFF.  AUTO means that Expanded Memory
will be available only when a program needs it.  ON means it will
always be available, and OFF means it is not available.  The
default state (which can be set as an option to QEMM.SYS) is
AUTO.  The current state can be checked and set using QEMM.COM.
The default state for Expanded Memory Emulation is enabled.  To
disable it, add the option FRAME=NONE to QEMM.SYS.  HIGH DOS RAM
Mapping is enabled by adding the option RAM to QEMM.SYS.  (Note
that this forces the initial state to ON, and it cannot be
overridden.) To load TSRs into this RAM, use the utility
LOADHI.COM with a command of the form: LOADHI [d:][path]program.
There must be a contiguous section of high memory that is large
enough to load the TSR, or LOADHI.COM returns an error, and loads
the TSR into conventional RAM.  You can get a map of the first
1MB of RAM by entering the command QEMM without any parameters.
This will also return the current 'state' of QEMM.SYS, and the
amount of Expanded Memory, if any.

                     DesqView386 AND TOPS

I recently tested DesqView386 2.2 (as well as QEMM-386 4.2 as a
stand-alone memory manager) with TOPS/DOS 2.1 and NetPrint 2.0 on
a Compaq386/20 with 2MB RAM, VGA, and Compaq DOS 3.31.  Results
were uniformly excellent on both AppleTalk and Ethernet IF the
basic rules of DesqView/QEMM/TOPS compatibility are followed.

Rule #1: Do not run DesqView on a TOPS Server.  There appears to
be a basic incompatibility between DesqView and TOPS' Server
functionality.  This applies not only to DesqView386, but also to
DesqView on a 386 without QEMM- 386, as well as to DesqView on a
286, 8086 or 8088.  It is fine to have the full client/server
software loaded, but if you have something published and someone
tries to access it, you will have problems.  Usually, both client
and server will eventually hang.  Note that I found no problem
being a TOPS Server when just QEMM-386 was loaded and active,
unless DesqView was loaded as well.  I did not test being a Print
Server, but I would expect similar results.

Rule #2: The LAP driver must have DMA set to none if QEMM-386 is
loaded and active ('state' is ON).  This is true in the case of
ALAP and ELAP503, although the symptoms using ALAP are much more
dramatic.  If ALAP is set to use DMA 1 or 3, and QEMM is ON, you
will hang when you load TOPS or NetPrint.  If QEMM is AUTO, you
will probably hang at some point after loading DesqView, or
otherwise accessing Expanded Memory from an application.  The
problems seem to take longer to develop when using ELAP503 with a
DMA channel, but they were unavoidable.  Since the default for
ELAP503 is DMA=0, this will not normally be a problem.  The rule
of thumb is, if you are using QEMM-386, disable DMA.

Rule #3: With DesqView, configure the LAP driver to use a
software access interrupt other than the default.  The default
software access interrupt used by all the TOPS LAP modules is 5C.
We suggest configuring the driver to use some other interrupt,
such as 60.  This can be most easily accomplished through the
"CONFIGURE" option in the SETUP program.

Rule #4: Load TOPS and/or NetPrint BEFORE loading DesqView.  All
TOPS and NetPrint functions can be executed from within DesqView
EXCEPT for the actual loading of the memory resident modules.

When the above four rules were followed, all the TOPS network
functions I tried worked flawlessly.  I was able to see network
servers and printers, print to network devices, mount remote
volumes, (and publish and act as a server, if DesqView was not
loaded), do bi-directional copying between two machines, and run
programs remotely, both from the command line in DOS with
QEMM.SYS on, as well as from DOS Windows in DesqView.  You can
even create a DesqView Program Information File for TOPSMENU and
CONFIGUR, and run them in a DesqView Window.  In one interesting
experiment, I modified the Program Information File for Microsoft
Word 4.0 to run off drive D:, then I mounted a Macintosh folder,
copied the contents of my Word subdirectory into it, launched
Word remotely off the Mac drive, opened a Word document, edited
it, saved it, and printed through NetPrint, all from within
DesqView with QEMM.SYS active.  I was able to perform all these
functions both with TOPS and NetPrint loaded in conventional RAM,
as well as when various TOPS and NetPrint modules had been loaded
into HIGH RAM with LOADHI.COM.

The same tests were performed with the previous version of
DesqView, version 2.01, and its companion QEMM-386, version 4.1,
with identical results, with one exception.  If you try to load a
TSR with LOADHI.COM, and there is insufficient contiguous HIGH
RAM available, LOADHI will inform you of the fact, and load the
program into conventional RAM.  If this occurred with a TOPS
module under QEMM-386 4.1, TOPS functions would no longer work.
It was necessary to LOADHI only those modules which would fit in
HIGH RAM, and do a conventional load on the others.  This problem
did not occur with QEMM-386 4.2.

It is important to keep in mind that different architectures and
designs are employed in different 386-based machines.  This can
sometimes result in different behavior from TOPS with 386
Expanded Memory Managers on different machines.  We have seen the
exact same programs and configurations work on one 386 machine,
and fail on another.  In general, reports from the field have
been uniformly positive regarding TOPS and DesqView386 when the
above- mentioned rules are followed.

             * * * E N D  O F  F I L E * * *